Overview
Having read a number of other SOA books, I've developed a pretty sound foundation of what SOA is in terms of the technologies that form its basis, and the relative importance of introducing a service abstraction layer between the business and IS domains.
However, this book (Service Orient or Be Doomed!) caught my attention for two fundamental reasons:
1. It has a strong Amazon rating, and
2. It provides a business (vice technical) perspective on the importance of SOA
I started reading the book late last week and quickly found it to be very well written and absolutely compelling with respect to the message that it conveys. The book's message looks something like this:
* Companies need to be more agile than ever in order to compete in today's economy
* Existing technical solutions are inflexible and prevent business agility
* Service-Oriented Architecture can result in increased business agility, more flexible technical solutions and significant ROI over time
* To make SOA viable, the business itself must become Service-Oriented, which means the technical concepts of abstraction, encapsulation and design-by-contract are now important business constructs that result in a more loosely coupled relationship between business activities (e.g. processes) and automation technologies
* SOA requires the "business" and "technology" domains to converge around a new business organizational construct referred to as service domains
* IS must rethink its organization and technology strategies to better align with the Service-Oriented business
* Resistance to Service-Orientation and SOA is expected because of the level of requisite change
* To overcome the expected resistance and create business agility, SOA must be championed by a senior person or group
* SOA must be planned for, and must begin with small, targeted pilot implementations
* SOA (a discipline) is not equal to Web Services (a technology)
As one editorial review put it:
"Jason and Ron are experts on Service-Oriented Architecture (SOA) and have written the first book that is aimed at helping a nontechnical businessperson understand why the SOA computing revolution is critical to business. Rather than provide a nerdy death via buzzword book, Jason and Ron take a humorous, clever, and insightful romp through this new technology and how it impacts business in general."
I couldn't agree more. The authors obviously understand the technical side of SOA, but they've gone the extra mile and actually provided a more business-side treatment of Service-Orientation that makes a very strong case for the need for most businesses to implement changes - and in many cases large, difficult changes - or ... in their words ... be doomed to inflexibility and failure.
The first five or six chapters of the book focus almost entirely on building a case for the need for Service-Orientation by providing historical perspectives on such things as the dot-com bubble and even back as far as the Industrial Revolution. For non-technical readers (e.g. business folks), the first few chapters may be a little ho-hum, but for the technical reader, the content of these chapters lays a strong foundation upon which the remainder of the book is based. In particular, the authors demonstrate how existing technologies, including middleware, EAI and even standalone Web Services, handcuff the business by creating less-than-flexible solutions that are very resistant to changes ... changes that the business MUST make in order to remain efficient and competitive.
More than any other SOA book that I have read (and I've read most of them), this book effectively makes that case that new shared mental models need to be developed and advocated wherein business- and technical-concerns are integrated into a holistic view of the business that is centered on the notion of a business Service that depends on an array of equally important business resources, e.g. people, material, technology, time, money, etc. In effect, the existing walls between the business and IS domains need to be removed, and in their place a service layer abstraction created that allows the business to compose solutions from Services that conform to meta-data driven "contracts."
The net effect of this approach is a more loosely coupled continuum between business operations and the resources (including technology) that facilitate those operations.
However, this new Service-Orientation and overarching SOA landscape introduces new complexities and abstractions as payment for the increased levels of flexibility and business agility. To manage this new complexity, the business needs enterprise architects and enterprise architecture that drive the Service-Orientation perspective into the enterprise's SOA architecture, and manage the organizations "meta-requirement" for overall business agility.
The authors suggest, and I agree, that a new breed of "Service-Oriented Architect" is desperately needed by the business in order to champion the SOA principles and architectural mandates represented by the Service-Oriented approach.
As an example of the sort of quantum changes that need to be made by a company in order to embrace and adopt Service-Orientation and SOA, the authors note that Services are never really "complete", nor are their requirements ever stable. Instead, the business requirements that a Service may address are subject to frequent change as the business continues to adjust its goals and objectives to meet a continuously fluctuating business environment. Therefore, customary software development lifecycles (SDLC) (e.g., waterfall, spiral, iterative, etc.) are not applicable to Service development because SDLCs assume that a project is completed and a deliverable is promoted into a lifecycle that results in the deployed artifact eventually being retired. However, in the Service-Oriented paradigm, a Service is never completed in the sense that development work is done. Instead, the Service is constantly subjected to new requirements and ongoing refactoring activities in order to keep the service relevant and useful to the business.
Perhaps most importantly, the book puts the concept of a Service squarely in a business context and shows how loosely coupled Services can be composed into business solutions without any direct knowledge of (aka coupling to) underlying technical resources that ultimately implement the service. The authors go to great lengths to demonstrate how important the resulting "loosely coupled" relationship between business logic and program logic is to the business' overall agility.
Lastly, I thought that the authors did a fantastic job of demonstrating how current technologies and solution techniques are too narrowly scoped and result in overly tight coupling between business and technical resources, inconsistent with the requirements of Service-Orientation and SOA. Thus, they make a strong and logically based argument that major changes are needed in order to successfully bridge the business and technology concerns into a cohesive enterprise model that exhibits the necessary quality attributes needed to make the business more agile.
Without reservation, I would highly recommend this book to any company stakeholder and all managers, technicians, architects, analysts and executives interested in and/or concerned about business agility, Service-Orientation, SOA, risk management, process control or corporate compliance (just to name a few).
Strengths
Overall, I thought the book's greatest strength was its underlying "business side" emphasis relative to the whole Service-Orientation issue. The authors set out to convince businesspeople of the need to adopt Service-Orientation and SOA, and I believe they did a great job of doing just that.
While some of the historical background material may be old hat for some readers, I thought the authors did a good job of comparative analysis and in doing so provided a larger referential foundation that was effectively reused throughout the book.
Also, I found the authors' treatment of the concept of loose coupling to be one of the best non-technical examples that I've seen in quite some time. I expect that all readers, especially business managers and executives, will grasp the otherwise heavy-weight concept of coupling in such a way that the virtues of SOA will become more apparent from a business operations perspective, rather than a purely technical (e.g. encapsulation and data hiding) one.
I thought the authors did a great job of describing the role of an architect, and in particular the unique idiosyncrasies of the Service-Oriented Architect role. Additionally, they made a very strong case for the need for an Enterprise Architecture group and went so far as to suggest that EA may need to "own" the company's SOA effort and be properly budgeted to do so.
Finally, I think one of the book's most compelling arguments is that major changes are needed vis-à-vis the status quo in order to realize the business benefits manifest in the Service-Oriented paradigm. Implementing Web Services is not enough (it's actually an anti-pattern (read: bad)). Rather, the business needs to incorporate IT into the business planning process, and IT needs to prepare for that role by rethinking its integration strategies (in particular) and probably implementing a non-trivial reorganization in order to eliminate silos and embrace service domains.
Weaknesses
Overall, I didn't find many weaknesses with the book.
However, if I had to finger one aspect of the book with a critical eye (which doesn't necessarily imply that it is a "weakness"), I would perhaps suggest that the books content is very poignant in its assessment of the current state of IT practices, and clearly suggests that more than one legacy IT role may be on the chopping block when a well-formed SOA practice is finally implemented. I expect that some readers may quake in their boots when they read some of the harder-hitting assertions made by the authors. However, I tend to agree with most (if not all) of the author's points.
On second thought, there is one observation that I made which I am comfortable noting as a weakness. Throughout the book, the authors note that a Service is exposed as a Contracted Interface that defines the relationship between the service consumer and the service provider. Given the critical role of the Contract and the central role that it plays in the whole SOA service abstraction layer, I found it noteworthy that the authors never really provide an example of what a contacted interface would look like (format) or consist of (content model).
Otherwise, no other weaknesses noted.
Recommendations
I would highly recommend this book to all interested parties of SOA or Service-Oriented business architecture and analysis.
Perhaps more importantly, I would encourage the book's widest dissemination among business and IS leadership teams. Ultimately, the book's message is intended for them.
